Skip to content

Extraction of library auto-detection / caching module in legacy/builder #481

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 24 commits into from

Conversation

cmaglie
Copy link
Member

@cmaglie cmaglie commented Nov 11, 2019

The purpose of this PR is to extract the library auto-detection logic out of the legacy/builder and move it into the arduino module. This is all preparation work to decouple the algorithm from the legacy builder.

The most difficult part is finding a meaningful "boundaries" for this module becuase at the moment it's very tied to the ex-builder context, BTW I think it's 90% done, the last piece that prevents the extraction of the module is the ctx.Logger() part, but this requires another, bigger, refactoring and integration with the Java IDE.

@matthijskooijman

@cmaglie cmaglie added status: in progress Work is in progress on this component/core labels Nov 11, 2019
@cmaglie cmaglie self-assigned this Nov 11, 2019
@cmaglie cmaglie force-pushed the legacy-removing-1 branch 2 times, most recently from 5a2cc3b to feb0437 Compare March 11, 2020 11:26
@cmaglie cmaglie force-pushed the legacy-removing-1 branch from feb0437 to 40f9e89 Compare March 20, 2020 09:16
cmaglie added a commit that referenced this pull request Apr 8, 2020
…627)

* Removed legacy utils.PrettyOSName function

* Removed some constants

Possibly a container structure for build properties may be defined later
with helper methods (like GetBuildCorePath() ... etc.) to help in
retrieving these properties.

* Removed unused Context parameter

* upgrade github.com/arduino/go-properties-orderedmap to v1.0.0
@cmaglie cmaglie force-pushed the legacy-removing-1 branch from 40f9e89 to ec36bd8 Compare April 9, 2020 09:19
@facchinm facchinm force-pushed the legacy-removing-1 branch from ec36bd8 to e3a1a68 Compare May 8, 2020 08:33
@cmaglie cmaglie force-pushed the legacy-removing-1 branch from e3a1a68 to d6097ff Compare May 29, 2020 10:41
@per1234 per1234 added the type: enhancement Proposed improvement label Feb 3, 2021
@github-actions github-actions bot closed this Mar 30, 2021
@per1234 per1234 reopened this Mar 30, 2021
Also added methods to Load and Save the cache from disk without the need
to pass cacheFilePath back and forth.
…ner_find_includes.go

There is no point in keeping those structures inside module types
because:

- they are used only in 'container_find_includes.go'
- the entry in Context is used only in for library discovery

This commit prepares for the extraction of the library discovery logic
from legacy package.
- Added 'Contains(...)' method (instead of sliceContainsSourceFile(...))
- Removed useless comparators
All the fields needed to perform library discovery have been moved into
the CppIncludeFinder so there is no more need to pass them around as
parameters making it much more lightweight.
Previously the Origin interface{} field was used to store the "origin"
of the source file (being sketch or library). Actually Origin is really
needed only to reconstruct BuildPath and RootPath when the origin is a
Library, in all the other cases we can reconstruct BuildPath and RootPath
looking inside Context.

With the above in mind, this commit removes the non-idiomatic
interface{} by replacing it with a Library, so now the meaning of the
SourceFile.Library field is "the library where the source file is
contained or nil if not part of a library".
I don't know the reason why it was not placed here already, the git log
doesn't give much hints. Anyway this change prepares for the next commit
where the Library field is being removed from SourceFile struct.
@cmaglie cmaglie closed this Feb 22, 2022
@cmaglie cmaglie deleted the legacy-removing-1 branch February 22, 2022 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: in progress Work is in progress on this type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants